Limit tracks per user, append "fallback" tracks, check x-forwarded-for header #28
Conversation
Try to use the quasi-standard X-Forwarded-For header to get the IP
address of the client, in case we are being reverse proxied. This is
technically spoofable, but given that the client has access to the
Mopidy WebSocket, they can much easier skip tracks this way:
mopidy = new Mopidy(); /*wait 1sec*/ mopidy.playback.next();
appending tracks e.g. via mpd will have lower precedence and be used when user-submitted songs have ran out. new user tracks are inserted before fallback tracks.
|
Hey. I think this mopidy-plugin has great potential. I like these additions by @girst , though I don't quite understand how the other implementation of "add" (and it's replacement use) allows songs to be queued by other frontend, like mpd with mpd-sima. Anyway, I think the idea is great. Any chance this PR will be merged (it's been lying around for a couple of years in a few days. @Lesterpig still active? |
|
On Mon, Oct 10, 2022 at 02:27:10PM -0700, grasdk wrote:
though I don't quite understand how the other implementation and use
"add" allows songs to be queued by other frontend, like mpd with
mpd-sima.
I'm not exactly sure what you are asking, but I'll try to give an
explanation. the "add" implementation was changed, so the server
controls the logic. this was necessary to control who can add how many
tracks.
secondly, this logic keeps track of the number of tracks inserted
through party, so any tracks added by other clients will stay at the
very end. the indended use case is for the party host to add a few
initial tracks, so that if requests dry up, the music doesn't just end;
meanwhile, tracks added by guests (through mopidy-party) will have
priority over those added through other clients.
|
|
Thanks for the explanation. I intend to familiarize myself more with this. I'm interested in the same functionality with the addition that an automated mpd-client like mpd-sima could queue tracks if the queue runs empty (again). So basically instead of pre-filling a playlist it could be continuously updated if party guests are lazy. Anyway, more important. Is @Lesterpig around to accept this pull request? |
|
On Tue, Oct 11, 2022 at 08:18:18AM -0700, grasdk wrote:
Thanks for the explanation. I intend to familiarize myself more with
this. I'm interested in the same functionality with the addition that
an automated mpd-client like mpd-sima could queue tracks if the queue
runs empty (again).
So basically instead of pre-filling a playlist it could be continuously
updated if party guests are lazy.
this should work with this patch. you don't even have to wait for the
queue to get completely empty.
Anyway, more important. Is @Lesterpig around to accept this pull request?
I'd be happy if this was merged, too :)
|
Wow, that is a long inactivity period, sorry for that! 😅 |
|
|
||
| def post(self): | ||
| # when the last n tracks were added by the same user, abort. | ||
| if self.data["queue"] and all([e == self._getip() for e in self.data["queue"]]): |
There was a problem hiding this comment.
Maybe it's on purpose but just in case: if there is no song in the queue, and one user has already added max_songs, they cannot add any music anymore.
|
Released as 1.1.0, let me know if you have any issue :) |
|
On Wed, Oct 12, 2022 at 12:25:54PM -0700, Loïck Bonniot wrote:
Maybe it's on purpose but just in case: if there is no song in the
queue, and one user has already added max_songs, they cannot add any
music anymore.
not on purpose, i probably didn't think about this edge case.
|
|
On Wed, Oct 12, 2022 at 12:49:57PM -0700, Loïck Bonniot wrote:
Released as 1.1.0, let me know if you have any issue :)
thanks for pulling my changes, also the dark mode one!
|
This pull does three things at once, apologies in advance. I can submit them individually if you want.
Here's the rationale for each feature/commit (further technical details in the commit messages):
max_tracks(configurable) items consecutively; once a second user queued one song, the first user's limit is reset. Slightly related to Multi user in rotation, one song at a time for each user #23. settingmax_tracksto0disables the limit (which is the default)While implementing /add, I noticed that you used a GET request for /votes -- I think this should be a POST too. I can add a commit (or another PR) if you want, but I didn't want to swamp you with unsolicited changes too much.